Network functions virtualization (Network Functions Virtualization, NFV) uses a general-purpose hardware device and a virtualization technology to bear a function of a dedicated device in a traditional network, to reduce high costs caused by deployment of the dedicated device. Software is not bound to dedicated hardware, so that a network device function no longer depends on the dedicated hardware. In addition, relying on a characteristic of cloud computing, resources can be shared fully and flexibly to implement quick development and deployment of a new service, and automatic deployment, scaling, fault isolation, self-healing, and the like are performed based on an actual service requirement. In an NFV architecture, a party that receives an instantiation request and processes instantiation of a corresponding service (deploys the service) based on the request is referred to as a provider of a virtualized service (service provider for short), and a party that initiates the instantiation request is referred to as a service requester.
A virtualized network service (Network Service, NS) in NFV may be, for example, an IP multimedia subsystem (IP Multimedia Subsystem, IMS) network service or an evolved packet core (Evolved Packet Core, EPC) service. One NS may include several virtualized network function (Virtualized Network Function, VNF) modules, also referred to as virtualized network elements. During virtualization deployment of an NS, a service requester first needs to submit a descriptor of the network service (Network Service descriptor, NSD) to a service provider. The network service descriptor is also referred to as an NS deployment template, mainly including topology structure information of a topology structure of the network service and descriptors of VNFs (VNF descriptor, VNFD) included in the network service. In the topology structure information, virtual link descriptors VLDs (virtual link descriptor) are used to describe links between the VNFs. A VNFD is a descriptor of a VNF, and is also referred to as a deployment template of the VNF. The VNFD includes information about a virtualization deployment unit VDU (Virtualization Deployment Unit), a connection point CP (connection point), a virtual link VL (virtual link), and the like that are included in the described VNF. The VDU may represent a virtual machine on which application software is installed. A description of the VDU includes a description of a requirement of the VDU on a virtual resource of the virtual machine. The CP represents connection information of the virtual machine, for example, virtual network adapter information, and may be represented by an IP address or a MAC address. The VL is a virtual link, in the VNF, that connects a plurality of VDUs, and may be represented by information such as bandwidth and QoS.
Among prior-arts, a YAML (Yet Another Markup Language) model defined by using the TOSCA standard may be used to describe a VNF deployment template (VNFD). Specifically, the VNFD may be described by using a TOSCA service template (service template). For example, the following is a deployment template of a router VNF:
Code (1)tosca_definitions_version: tosca_simple_profile_for_nfv_1_0topology_template: inputs: substitution_mappings:# Describe which CPs act as external connection points toconnect to external networks.  node_type: tosca.nodes.nfv.VNF.VNF2  requirements:   virtualLink: [CP4, virtualLink] # Information about a specified external connection point   virtualLink: [CP6, virtualLink] # Information about a specified external connection pointnode_templates: VDU1:    # Node identifier and node    information of VDU1   type: tosca.nodes.nfv.VDU   requirements:    - host:# Requirement on a virtual machine     properties:      num_cpus: { equal: 2 }      mem_size: { greater_or_equal: 2 GB}   Capabilities:  # Information about a scalable quantity  of instances    scalable:     properties:      min_instances: 10   # Minimum quantity of instances: 10      max_instances: 20   # Maximum quantity of instances: 20 VDU2:   type: tosca.nodes.nfv.VDU   requirements:    - host:     properties:      num_cpus: { equal: 2 }      mem_size: { greater_or_equal: 2 GB}   Capabilities:  # Information about a scalable quantity  of instances    scalable:     properties:      min_instances: 10   # Minimum quantity of instances: 10      max_instances: 20   # Maximum quantity of instances: 20VDU3:   type: tosca.nodes.nfv.VDU   requirements:    - host:     properties:      num_cpus: { equal: 2 }      mem_size: { greater or equal: 2 GB}   Capabilities: # Information about a scalable quantityof instances    scalable:     properties:      min_instances: 10  # Minimum quantity of instances: 10      max_instances: 20  # Maximum quantity of instances: 20CP1:# Deployment information of CP1   type: tosca.nodes.nfv.CP   requirements:    virtualbinding: VDU1  # CP1 is attached to VDU1 and is  connected to VL1.    virtualLink: VL1CP2:# Deployment information of CP2   type: tosca.nodes.nfv.CP   requirements:    virtualbinding: VDU1    virtualLink: VL2CP3   type: tosca.nodes.nfv.CP   requirements:     virtualbinding: VDU2    virtualLink: VL1CP4   type: tosca.nodes.nfv.CP   requirements:    virtualbinding: VDU2CP5   type: tosca.nodes.nfv.CP   requirements:    virtualbinding: VDU3    virtualLink: VL2CP6   type: tosca.nodes.nfv.CP   requirements:    virtualbinding: VDU3VL1   type: tosca.nodes.nfv.VL.ELAN   properties:    # omitted here for brevity   capabilities:    -virtual_linkable     occurrences: 5VL2   type: tosca.nodes.nfv.VL.ELAN   properties:    # omitted here for brevity   capabilities:    -virtual_linkable     occurrences: 5
An example diagram of the deployment template of the corresponding VNF may be obtained based on the foregoing VNFD, as shown in FIG. 1. The VNF described by the code (1) includes three VDUs: the VDU1, the VDU2, and the VDU3, six CPs from the CP1 to the CP6, and two VLs: the VL1 and the VL2. The code virtualbinding: VDU1 and the code virtualLink: VL1 that are included in the CP1 indicate that the CP1 is attached to the VDU1 and connected to the VL1. The code virtualbinding: VDU1 and the code virtualLink: VL2 that are included in the CP2 indicate that the CP2 is attached to the VDU1 and connected to the VL2. Similarly, the code included in the CP3 indicates that the CP3 is attached to the VDU2 and connected to the VL1, and the code included in the CP4 indicates that the CP4 is attached to the VDU2, the code included in the CP5 indicates that the CP5 is attached to the VDU3 and connected to the VL2, and the code included in the CP6 indicates that the CP6 is attached to the VDU3. The code virtualLink: [CP4, virtualLink] and the code virtualLink: [CP6, virtualLink] indicate that the CP4 and the CP6 act as external connection points of the VNF to connect to external networks.
In practical application, there is a requirement of selecting different VDUs and VLs from a VNFD for deployment depending on different deployment requirements, instead of deploying all VDUs and VLs in the VNFD for whatever application. For example, in the previously described router instance, the VNFD may include two deployment flavours. A first deployment flavour includes the VDU1, the VDU2, and the VL1, and a second deployment flavour includes the VDU1, the VDU2, the VDU3, the VL1, and the VL2, and the VDU3 may be a firewall module. When the router VNF is deployed in an internal network, deployment may be performed according to the first deployment flavour, and the firewall module VDU3 is not required. When the router VNF is deployed at a network edge, deployment needs to be performed according to the second deployment flavour. FIG. 2(a) and FIG. 2(b) show deployment example diagrams of the first deployment flavour and the second deployment flavour.
However, according to the prior-art VNFD described by using the TOSCA model, it may be found that a plurality of TOSCA service templates need to be used if a plurality of deployment flavours need to be described, resulting in a waste of resources.